The manner in which USB peripherals are attached to a USB Host Controller and the manner in which USB drivers communicate with their corresponding devices make it difficult to prevent malicious software from mounting different classes of attacks that attempt to modify the USB topology. Such attacks may take various forms such as, for example, substitution attacks and snooping attacks.
A substitution attack involves substituting an illegitimate USB device for a legitimate device without the system recognizing that a substitution occurred. Each USB device is attached to a port on either a root hub or an external hub. A hub driver controls the state of its hub ports by sending certain USB commands over the hub's default pipe (endpoint 0). A malicious driver may hide a programmable USB device attached to one of the hub ports by disabling the port to which the device is connected. The driver then may be able to disable a port of a real keyboard that is attached to the same hub and enable the port of the programmable device. In addition, the malicious driver may set the USB address of its programmable device to the address that was assigned to the keyboard it disabled. The end result is that the real keyboard is spoofed by a programmable device, and the driver for the keyboard is not aware that it is talking to a different device. In sum, the system believes that input data is generated by the keyboard when the data is generated programmatically by an adversary.
Another type of attack, the snooping attack, attempts to modify USB topology by taking advantage of a process in which a device driver reads data from its device by sending it an appropriate USB command. Some data sent by a device ideally should not be read by any entity besides the applicable device driver. An example of such case is when the device has to exchange an encryption key with the driver so that the driver can use the key for decrypting data that the device is going to generate later. An adversary may obtain sensitive data by either sending an appropriate command to the device or by mounting an attack in which the adversary grabs data en route to the requesting device driver. Additionally, it is recognized that a software solution may make it more difficult for an attacker to obtain sensitive information, but software alone likely cannot provide full protection against such attacks.
Additionally, in a computer system with a USB Host Controller and USB peripherals connected to it, it is desirable for software to be able to obtain information regarding USB topology. It is currently possible for legitimate system software to obtain such information. Malicious software, however, may tamper with topology information such that legitimate software may not be able to verify that topology information it receives appropriately reflects actual USB topology. For example, an adversary may program a USB device so that it looks to the system like a different device, such as a keyboard. Because the system may need to secure certain USB input devices in order to establish a trusted path with a user, mounting this attack leads the system to “trust” a keyboard device even though it is not a really a keyboard. A malicious driver mounts the attack by sending a USB command that configures a physical programmable device. The host controller driver queries the device for its USB descriptors, and the device returns descriptors indicating that the device is a keyboard. Thus, the system loads a keyboard driver for controlling that device.
This driver then waits for input data to be generated by the device. At that point, the malicious driver can trigger the device to generate one or more keystrokes by sending an appropriate USB command to the device. When these keystrokes are generated, the keyboard driver sends the corresponding keyboard events to the operating system. The end result is that the malicious driver can inject input events into the system. This also provides the malicious driver with the ability to have the device “playback” a certain keystroke sequence at a specific time, which may create general problems and may even enable the driver to inject input into a trusted input path as if the input was generated by a trusted device.
There is a need, therefore, for systems and methods to prevent attacks on USB systems that attempt to change USB topology and to audit USB topology to ensure that the information that the system maintains regarding the attached USB devices appropriately reflects the actual USB topology. The systems and methods ideally should not be based solely in software.